Skip to main content

How to build an App

IDHub provides a robust and very user-friendly process for onboarding apps and managing them. This document would elaborate on how to onboard your app (disconnected), set up attributes for your app, approvals for the app and set the owners for the app.

How to Request On-boarding for the Application

  • Go to ‘Manage Catalog' in the Admin Module of IDHub using the credentials of a user that has the role of 'System Administrator' with them. To learn more about IDHub roles, click here
  • Upon reaching Manage Catalog, Click on ‘Create Application' and 'Create Application' again from the dropdown

The wizard opens up with a few pages that need to be filled. Below is more info on that.

Entering the Basic Information about the app

In this section you need to enter some basic information about the application which are as follows:

  • Application logo
    • This can be uploaded via a png, jpeg file not exceeding 25MB
  • Application name
    • This is Target System whose information is being entered into IDHub
  • Description
    • You can enter some description for the application you are on-boarding for better user understanding
  • Search keywords
    • Here you can enter some keywords for the application which will aid in robust searching
  • Application URL
    • This is for single-user redirection to all their applications

Understanding Business Owner and IT Owner for the application

You need to decide then who is going to be your IT Owner and Business owner for the application.

  • Business Owner
    • He/She is an individual in charge of approving all modifications to the application on a business strategy level
  • IT Owner
    • He/She is an individual in charge of IT-related management of the application

Setting Approval Workflow for the application

Setting an approval workflow for the application is a critical step in onboarding the application. Choosing a workflow helps in defining what approval and fulfilment flow the access requests will take for the provisioning and de-provisioning of user accounts

IDHub provides you with some out-of-the-box workflow which you can select from the dropdown. You can also easily customize the pre-loaded workflows or create your custom workflow as per your business needs and choose that workflow in the application onboarding accordingly.

Setting Approvers for the Workflow

Some workflows need to define the approver groups who will be in charge of a particular stage of approving

Fulfilment of the application

An IDHub out-of-the-box workflow needs a fulfiller group assignment as well to complete the provisioning of access requests manually into the target system and mark the task as Done in IDHub

Understanding other items in the application onboarding wizard

  • Risk Level
    • This metadata is used to communicate risk scores to users of the application. A person who has access to the application will have a total risk score, which will be divided into three categories: High, Medium, and Low. High is a risk score of 3, Medium is a risk score of 2 and Low is a risk score of 1
  • Certification Tags
    • This multi-tag keyword information may be applied as a filter in many different locations. The most frequent usage of this is to detect certain compliance-related tags, such as HIPAA, NERC-SIP, etc., during access reviews.
  • Requestable
    • This serves to determine if the application is available to end users for manual requests. A user may access an application in a variety of ways. This just prevents the application from being seen in IDHub's Search Catalog - User Module. Even after being non-requestable here, users can still obtain an application directly via an IDHub Role or by Reconciliation of an application.
  • Create a user on Reconciliation
    • This checkbox can be used to designate whether the programme is to be trusted or non-trusted. If no matching user is identified, a trustworthy application can create new accounts in IDHub. It is only permitted for a non-trusted application to link user accounts to current users. Information is not retrieved from any account for non-trusted applications if it cannot be matched with an existing user.
  • Attach a Custom Form
    • This is to choose a custom form for your application attributes. While user requests can be made with the attributes manually added in the attributes page of this application (in the next section), a custom form can be picked to consider as an overlay to make the attributes more understandable and easy to request

Understanding Attributes for the app and configuration.

Each Target System requires a specific collection of attribute data before the user may request the creation of an account. For instance: A new email, first and last names and phone numbers are required when opening an account on Google & others. Similarly, each application needs a certain collection of data to establish a user account. This page serves as a bridge between the application's desired properties and IDHub user attributes.

note

Any application that an organisation currently uses or may use in the hereafter is connected to through the IDHub application. Each of these applications has its own set of specifications for setting up and managing user accounts. This attribute page aids in mapping certain properties and matching them with IDHub user attributes.

Since the Target System attributes are not automatically fetched for disconnected applications, you have to manually enter this in the page and map it with the IDHub attribute (if needed)

info

Mapping every application attribute with an IDHub is not mandatory. There can be attributes that the application has without an IDHub user attribute.

Required

Upon user account creation, modification or reconciliation, if an attribute has to be sent as the pre-requisite from the Target System, then that attribute is marked as ‘Required’ while application creation.

The most common fields are the unique identifiers like login, and email which are needed by most.

Multi-Value

Certain data types allow multiple values for a single attribute. This field is to be used for them.

Ex: Date if chosen as a multi-value, becomes a date range field. Ex: 01/01/1991 - 31/12/1991

Account Field Name

Every application has an attribute which is its unique identifier for the account. It is mandatory to mark an attribute as ‘Account Field Name'

Reconciliation Key

IDHub requires user accounts to be mapped to users. For the mapping to be successful, a reconciliation key configuration is used. An attribute is made a reconciliation key to match a user with its account.

Ex: User Email is mapped with Google Email Field to assign the correct Google account to a user in IDHub

Understanding Sync Direction for the Application Attributes.

Apart from the mapping of an Application, adding Sync direction is an important part of Application onboarding. 4 different kinds of sync direction can be used. Each is explained in detail below:

  • Bi-directional Sync
    • This sync direction indicates that upon provisioning an account from IDHub to Target System, the attribute will be mapped to the user attribute in IDHub with the user account attribute in Target System. This also indicates that upon reconciliation of information from Target System to IDHub, the mapped user attribute will be matched with the user account attribute value received on reconciliation
  • App-to IDHub Sync
    • This sync direction indicates that upon provisioning an account from IDHub to Target System, the attribute will ‘NOT’ be mapped to the user attribute in IDHub with the user account attribute in Target System. This also indicates that upon reconciliation of information from Target System to IDHub, the mapped user attribute will be matched with the user account attribute value received on reconciliation
  • IDHub to App Sync
    • This sync direction indicates that upon provisioning an account from IDHub to Target System, the attribute will be mapped to the user attribute in IDHub with the user account attribute in Target System. This also indicates that upon reconciliation of information from Target System to IDHub, the mapped user attribute will ‘NOT’ be matched with the user account attribute value received on reconciliation
  • No-Sync
    • This indicates that upon provisioning or reconciliation of the account from IDHub to Application or vice-versa, the information is not updated to the mapped user attribute
note

User Account Vs User attribute

User: The attributes User Login, First Name, Last Name etc present in the User Schema of IDHub is the user attributes

User Account: The attributes which are defined in this attribute page while application creation are user account attributes specific to that application

caution

Keeping bi-directional sync for every application attribute is not recommended. If there is an update in a user account attribute, it will update all applications attributes mapped with that user attribute as part of managing identity. Thus only desired attribute mapping should be done.

Understanding the Data Types for the Application Attributes

  • String - This is to enter alphanumeric values in the field - Ex: ‘James is a user in the sales department
  • Boolean - This is to enter only 2 values in it - Ex: True or False; 0 or 1
  • Date - This is to enter only the date in the field - Ex: 01/01/1991
  • Date Time - This is to enter the date and time in the field - Ex: 01/01/1991 00:00:00
  • Time - This is to enter only time in the field - Ex: 00:00:00
  • Bigint - This is to enter only integers in the field - Ex: 023458492455
  • Object - This is to enter only objects in the field

This will be expanded to use drop-down lists too if custom forms are used.

Entitlement

Entitlements are permissions that would be provided to each user accounts in the Target System.

note

The definition of an entitlement varies from Target System to Target System. For Active Directory, groups can be entitlements whereas Atlassian has Jira Projects and Confluence Spaces as entitlements. Entitlement can be fine grained or high level permissions depending on the organisations need to manage their permissions

This is manually entered while application creation. Things needed to make an entitlement in IDHub:

  • Entitlement Name - This is displayed to users while requesting
  • Entitlement ID - A unique identifier is assigned to each entitlement named (this is auto-assigned for connected applications)
  • Search Keywords - This is used for filters and quick searches
  • Description - This is used to give more information to users while requesting
  • Workflow - Choosing a workflow helps in defining what approval and fulfillment flow the access requests will take for provisioning and de-provisioning of particular entitlement
  • Approvers- Some workflows need to define the approver groups who will be in-charge of a particular stage of approving
  • Fulfillment - An IDHub out-of the box workflow needs a fulfiller group assignment as well to complete provisioning of access requests manually into the target system and mark the task as Done in IDHub
  • Risk Level - This is a metadata to distribute risk scores to individuals who has access to the entitlement. High is a risk score of 3, Medium is a risk score of 2 and Low is a risk score of 1 added to the total risk score of an individual who has access to the entitlement
  • Requestable - This is used to identify whether the entitlement is visible to the end users for requesting manually. There are many ways a user can get access to an entitlement. This only prohibits visibility of the entitlement in Search Catalog - User Module of IDHub. Users can get an entitlement directly via an IDHub Role or via Reconciliation of entitlement for accounts too even after being non-requestable here.

The request for the application is submitted upon successfully entering all entitlements.

Understanding the approval process of On-boarding request

After entering all the required information, the request is submitted for approval to the ‘Access Manager' of IDHub. This is an OOTB Role dedicated to managing application-related changes.

info

This approval and onboarding process is managed by an OOTB workflow named ‘Access Manager Workflow’

Access Manager upon going to the ‘Tasks' page upon logging into IDHub can Claim and Approve the task.

info

Requests would also be generated when you on-board the app. You can view your requests in the ‘Requests' page. Click Here to view details about how you can view/track your requests.

Post approval, the application is successfully onboarded with desired attributes, entitlements and configurations as entered.

tip

The newly added application can be viewed in the ‘Manage Catalog' section of IDHub after approval. Click here to view more details.